Here is a big huge pile of code that demonstrates:
Animation with QuickDraw
Asynchronous Sounds
AppleEvents
Synchronizing Animation using AppleEvents
A sample network video game
If I had the time to start over, I would drag the project to the trash and start again in a much cleaner way. When I started this project, we did not know how or even if the AppleEvents would work, and I was unsure of how to fit them in. So, what you are getting is code that has been through an evolutionary process - not designed well from the start.
DISCLAIMER AND BUG WARNING
There are BUGS. Numerous BUGS, I'm sure. This is still in development, and it may crash your mac, so please don't run it while you have important stuff in the background.
If you FIX a bug in the code, please send me a link with the fix. Or if you think you know what is causing a problem, let me know. If you have a crashing bug report, let me know.
I will be updating the code and putting a much cleaner version on a later CD.
Remember, this is work in progress, and far from perfect. Please send me bug reports!
WARNING WARNING WARNING:
ZAM is not compatible with virtual memory. Turn off VM before you run it. It dies in the Finder in vSynchWait.
Without VM running, it should crash MUCH less. However, it may still crash.
HOW TO USE IT:
Each machine needs a copy of the application and all of the following files:
ExplosionFrames.rsrc
FireBallFrames.rsrc
nuTankFrames.rsrc
ZAM Sounds
These files must be in the same directory as well. Program linking must be turned on. Run the app. One person selects New and chooses the other player. Use the numeric keypad to control your ..uh tank.
8 = accelerate
5 = decelerate sort of
4 = rotate left
6 = rotate right
shift = fire
These must be the numeric keypad keys because I read the key map. Change the code if you don't like these keys.
The tanks don't explode. But you do get a cool sound after you shoot one long enough.
COMPILING THIS
Precompile Dude #includes.c and name it DudeHeaders, and put it next to the MacHeaders file in your THINK C folder.
WHAT DOES NOT WORK OR IS INCOMPLETE
I have never tried compiling with MPW C. I may fix this for the next release.
There may be a lot of dead code.
The game ONLY WORKS ON A MACHINE WITH A NUMERIC KEYPAD.
The game only supports 640 x 480. Just change the WIND 128, and get a different background PICT for screens of other sizes.
You should change the key code scanned for PowerBooks.
The missiles sometimes leave artifacts.
The remote sprites frame tasks do not animate. - They move around OK, but they do not change frames as they should.
The tanks do not really explode, but you do hear Annabel saying "Sorry Bub, you lose". If anyone has some cool explosion art to send me, I'll fit it in. I did not make them explode because I did not have an explosion worthy enough. Sorry.
Sometimes the explosions are out of sync. You will see them on one screen but not on the other.
Collision detection is still weak - I am only using rectangle detection, and then checking the size of intersection to make sure it is large enough. This does not work that great, I should do a region version. Collision detection is one of my favorite subjects, so please send me a link if you'd ever like to talk about it.
I do not call AEInteractWithUser before displaying an alert. I should.
Sometimes, when you hit the other player the explosions live a lot longer then they should and the
sound keeps playing. I'd like to fix this one, so if you do, be sure to let me know.
BRIEF DESCRIPTION OF THE NETWORKING ARCHITECTURE
The CoMation™ architecture used by this code is impure - I would like to do a version where the animation module (sprite manager) knows more about the AppleEvents and remote sprites, and manages them for the application, in a completely isolated way. Maybe next time, maybe never. But it works in this version, messy as it may be. It is the first generation CoMation™ architecture.
After one of the players uses the PPCBrowser to select a game to link to, the game begins. Ten times per second an AppleEvent is sent to the opponent Mac giving the position and heading of the Tank and missiles. The next Sync event is not sent unless an acknowledgment is received from the opponent mac. This prevents the network from being flooded, and prevents events from stacking up on the other side.
If you want to build a version that only runs on one mac to test the animation or sounds, set the NO_NET #define to 1 in GameAEvents.h. I hope this still works. It is not that fun to play though, but you can drive the tank around. If it does not work, then do a global search on AESEnd and comment them out.
One of the important things I learned doing this project was that (drum roll.....) AppleEvents are not very suitable for a real time animated game. I had many problems keeping things in synch, and went through many iterations of the networking code. What is provided in this sample BARELEY WORKS adequately.
One drawback of the AppleEvent code, is that overall it slows ZAM down, so the animation does not look as nice as it could. Oh well. I thought about ripping out the animation code and doing an animation only sample, but samples like this are already available. See "SpriteWorld" on the developer CD, as well as various online services.
BRIEF DESCRIPTION OF THE ANIMATION ARCHITECTURE
This game uses the Time Manager to time the animation between frames and movement.
The file xthing.c contains the Time Manger code. It manages a list of tasks that need to be run at non-interrupt time. When a task is started it calls StartXThing, giving how long till it fires, a callback routine, and a reference value. Then a Time Manager task is launched. In the idle loop the program calls ProcessXThingTasks, which then executes all the tasks whose timer has expired. The xthing.c file is a pretty re-usable chunk of sample code.
Each sprite has a movement task and a frame task that operate independently. Every time the frame task fires, the frame is advanced to the next one, or wraps back to the first one. Each frame may also have a callback routine associated with it, which will also be called. There are also various flags that may be set to control this. There are WAY too many flags, sorry about that.
When the movement task is fired the location of the sprite is updated by its velocity, both kept in Fixed point. This only happens, of course, if the appropriate flags are set, otherwise it is up to your Movement Filter to move the sprite. A movement filter may also use the default movement, and then modify it in someway, perhaps forcing an object to keep to a certain path.
The visual graphic data structures break down like this:
SpriteLayer - list of sprites at a certain layer, includes background and owner window
Sprite - one character on the screen
SpriteFrameSet - the list of animation frames for the sprite
frameInfo - the number of frames, current frame + mask, etc. in this set
frameCell - one animation frame
Right now the animation engine knows about RemoteSprites, but leaves it to the application to establish the connection, set the right flags, and fill in the changes. I would like to see the sprite manager take care of this, because I don't think it is too easy to use.
ANOTHER BRIEF DESCRIPTION OF THE ASYNC SOUND
This is a pretty re-usable chunk of sample code.
At initialization my sound unit is brought to life with the InitSounds call. The name of the file containing the sounds is passed, and this file is opened and pulled from the resource chain at this point. This prepares the unit for managing 4 async sound channels
Whenever a sound is desired this routine is called:
OSErr PlaySndAsynchChannel(short sndID, short chanNum, short priority)
sndID is the resource ID of the snd in the sound resource file. The sound unit loads it for you. chanNum is a value from 0 - 3, which represents which sound channel to play the sound on.
Priority is a value associates with each sound that represents how important that sound is. If you try to play another sound on the same channel with a lower priority, it won't play. If you play one with a higher priority, the current sound will be stopped and yours will be started.
The sound unit uses a callback to set a flag to indicate that the sound channel needs to be closed. In the idle loop SoundKeeper() is called, which gives the sound unit a change to clean up any old channels.
At the end of the program FreeSounds() is called to release any channels before quiting. FreeSounds may also be called on a switch event, but it currently is not.
One messy things used by ZAM: SoundDisable is called to stop all sounds and ignore all other sound requests, except those sent PlaySndAsynchChannelNow, which is just like PlaySndAsynchChannel, except it ignores the SoundEnable flag.
OTHER MISC STUFF
PixiZAM - this is the start of direct blitter sprite manager, I never did more than test it out to make sure it works. One advantage of this is that It does not use QuickDraw structures, so it can store images without color table information and other stuff which makes them use less memory at runtime, and also the images can be primed for copying instantly without much overhead. One disadvantage is that this does not use QuickDraw structures, so it is not easy to write a QuickDraw version of the code. I'd have to write two versions of the animation engine to use this. It may be worth it. Again, if you write to the screen you MUST have a QuickDraw version of your code if you hope to keep your program running on future Macs. I did not incorporate this, but I am releasing it because it was part of the project and might inspire some of you out there to write a better one and send it to me.
ExplosionSprites are probably the best sprites in the game, the most animation frames, sounds, etc. Check them out.
THANKS TO THOSE WHO HELPED:
C.K Haun, Tony Myles, Craig Fryar, Stuart Cheshire, Steve Newman, Antono Loewald, Mike Schlachter for his rad guitar, Annabel Hertz for her rad voice, Nitin Ganatra, Randy Thelen, Brian Miyakusu, Bill Dugan,Mark Johnson (for thinking this a worthy project), and others here at Apple.
